NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/5145

Internet Message Format | 1996-08-05 | 3.9 KB

Path: news.tau.ac.il!usenet
From: Avi Lev <[e-mail]>
Newsgroups: comp.sys.amiga.programmer
Subject: Re: 680X0 -> PPC translator?
Date: Mon, 11 Mar 1996 10:31:39 +0200
Organization: Sapiens Technologies
Message-ID: <[e-mail]>
References: <4h4fk6$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: honda.sapiens.co.il
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (WinNT; I)

Volker Barthelmann wrote:
>
> Avi Lev ([e-mail]) wrote:
> :
> : Hi, IMHO, the way i would try to solve the problem is by going
> : through all the programs' segments picking up all the different
> : calls which are addressed to the program itself (not to outside
> : libraries or devices), which is easy to solve cuz every such
> : call must use the A6 as the base register and so every other
> : call is to code within the program, then all there's to be done
>
> This is completely wrong. External calls don't have to use a6 as base
> register and calls with a6 as base don't have to go outside.
>
> And the called address can be calculated during program execution.
>
> Volker

Well, even so it still doesn't affect the translation process and that's simply becuase in
order to make a dynamic call (ie run-time address calc.) the base address of the function is
referenced somewhere in the program right?! so you can collect all these addresses and then see
where they're used as jump/call operands in an indirect call somewhere else in the program.
remember that all such addresses are 'lea'ed somewhere in the program and probably stored in
some variable in memory and when needed is used to load an address register for making the jump
or simply used directly, in either case to resolve the problem of dynamic address resolution,
address context analysis must be performed on EACH such address in the program, while it
implies hugh data structures, it is very much theoratically possible. also bear in mind that
all external references are assumed to be translated code already, so we don't care about that
but ALL internal references can be resolved because SOMEWHERE, SOMEONE must have used them and
don't tell me that function addresses are being used in arithmatic calculations, that is simply
weird programming, don't you agree and so the exact entry point is located somewhere in the
program, hey no one said that the translator has to be a stupid one, hell no, it is pretty much
intelligent in that respect, that is one of the fields in which it excels i think, to be able
to resolve dynamic addresses. if the branch is to some externally allocated memory, in which
case you don't have an address, then this falls under the heading of self
modifying/relocating code and then you have to simply change the source bytes, meaning the
code bytes being copied to PPC code ofcourse, however a problem arises if the code size differs
from the translated code size, then you'll have to locate the code that does the copying and
modify it accordinly which i admit can present a barrier but hey, for an entry level translator
it does provide alot of answers to most other problems, right?! i think that some run-time
solution must be provided in that case, meaning that if the translated program, running under a
PPC enounters a 680x0 instruction, that should trigger an exception which then translates
the code and continues as if nothing had happened, but the processor has to support that at
the hardware level, otherwise more advanced algorithm are needed. and as for distinguishing
data residing in code hunk, nothing could be simpler than simply simulating the running of the
program (ie following its flow) and again make intelligent decision based on the context of all
memory locations used in the program, if a memory area is used for i/o but not for execution
it's a data section otherwise it's a code section.